Hacker's Arsenal - The Cutting Edge of Hacking/Hacker's Arsenal - The Cutting Edge of Hacking.iso/texts/virus/Guide to the Selection of Anti-Virus Tools and Techniques.txt

Text File | 2001-07-11 | 82KB | 1,774 lines

NIST Special Publication 800-5

Guide to the Selection of Anti-Virus Tools and Techniques

W. T. Polk
L. E. Bassham

Dec. 1992

National Institute of Standards and Technology
Computer Security Division


Ascii text version:
No references or indices.
Tables at end.
Footnotes in text, following paragragh where they occur.

Some references to documents or other sections within the text
may be missing from ascii version!




            Abstract

Computer viruses continue to pose a threat to the integrity and availability of
computer systems. This is especially true for users of personal computers.  A
variety of anti-virus tools are now available to help manage this threat. These
tools use a wide range of techniques to detect, identify, and remove viruses.

This guide provides criteria for judging the functionality, practicality, and
convenience of anti-virus tools. It furnishes information which readers can use
to determine which tools are best suited to target environments, but it does
not weigh the merits of specific tools.




Table of Contents

1.0 Introduction
  1.1 Audience and Scope
  1.2 How to Use This Document
  1.3 Definitions and Basic Concepts
2.0 Functionality
  2.1 Detection Tools
    2.1.1 Detection by Static Analysis
    2.1.2 Detection by Interception
    2.1.3 Detection of Modification
  2.2 Identification Tools
  2.3 Removal Tools
3.0 Selection Factors
  3.1 Accuracy
    3.1.1 Detection Tools
    3.1.2 Identification Tools
    3.1.3 Removal Tools
  3.2 Ease of Use
  3.3 Administrative Overhead
  3.4 System Overhead
4.0 Tools and Techniques
  4.1 Signature Scanning and Algorithmic Detection
    4.1.1 Functionality
    4.1.2 Selection Factors
    4.1.3 Summary
  4.2 General Purpose Monitors
    4.2.1 Functionality
    4.2.2 Selection Factors
    4.2.3 Summary
  4.3 Access Control Shells
    4.3.1 Functionality
    4.3.2 Selection Factors
    4.3.3 Summary
  4.4 Checksums for Change Detection
    4.4.1 Functionality
    4.4.2 Selection Factors
    4.4.3 Summary
  4.5 Knowledge-Based Virus Removal Tools
    4.5.1 Functionality
    4.5.2 Selection Factors
    4.5.3 Summary
  4.6 Research Efforts
    4.6.1 Heuristic Binary Analysis
    4.6.2 Precise Identification Tools
  4.7 Other Tools
    4.7.1 System Utilities
    4.7.2 Inoculation
5.0 Selecting Anti-Virus Techniques
  5.1 Selecting Detection Tools
    5.1.1 Combining Detection Tools
  5.2 Identification Tools
  5.3 Removal Tools
  5.4 Example Applications of Anti-Virus Tools
    5.4.1 Average End-User
    5.4.2 Power Users
    5.4.3 Constrained User
    5.4.4 Acceptance Testing
    5.4.5 Multi-User Systems
    5.4.6 Network Server
6.0  Selecting the Right Tool
  6.1 Selecting a Scanner
  6.2 Selecting a General Purpose Monitor
  6.3 Selecting an Access Control Shell
  6.4 Selecting a Change Detector
  6.5 Selecting an Identification Tool
  6.6 Selecting a Removal Tool
7.0 For Additional Information



1.0 Introduction

This document provides guidance in the selection of security tools for
protection against computer viruses. The strengths and limitations of various
classes of anti-virus tools are discussed, as well as suggestions of
appropriate applications for these tools. The technical guidance in this
document is intended to supplement the guidance found in NIST Special
Publication 500-166, "Computer Viruses and Related Threats: A Management
Guide".

This document concentrates on widely available tools and techniques as well as
some emerging technologies. It provides general guidance for the selection of
anti-virus tools, regardless of platform. However, some classes of tools, and
most actual products, are only available for personal computers. Developers of
anti-virus tools have focused on personal computers since these systems are
currently at the greatest risk of infection.

footnote: Certain commercial products are identified in this paper in order to
adequately specify procedures being described. In no case does such
identification imply recommendation or endorsement by the National Institute of
Standards and Technology, nor does it imply that the material identified is
necessarily the best for the purpose. footnote

1.1 Audience and Scope

This document is intended primarily for technical personnel selecting
anti-virus tools for an organization. Additionally, this document is useful for
personal computer end-users who wish to select appropriate solutions for their
own system. This document begins with an overview of the types of functionality
available in anti-virus products and follows with selection criteria which must
be considered to ensure practicality and convenience. The body of the document
describes specific classes of anti-virus tools (e.g., scanners) in terms of the
selection criteria. This document closes with a summary comparing the different
classes of tools and suggests possible applications.

The guidance presented in this document is general in nature. The document
makes no attempt to address specific computer systems or anti-virus tools.
However, at this time the computer virus problem is most pressing in the
personal computer arena. Consequently, most types of anti-virus tools are
available as personal computer products. As a result, some information will
address that specific environment.



1.2 How to Use This Document

The remainder of this section is devoted to terminology and basic concepts.

Section 2 describes the different types of functionality that are available in
anti-virus tools. Several different types of detection tools are described, as
well as identification and removal tools. This information should assist
readers in identifying the classes of products appropriate for their
environment.

Section 3 describes some critical selection factors, including accuracy, ease
of use, and efficiency. The description of each of these factors is dependent
on the functional class of product in question. These selection factors are
used to describe product classes in the sections that follow.

Section 4 describes specific classes of tools, such as scanners or checksum
programs, and the techniques they employ. This section provides the reader with
detailed information regarding the functionality, accuracy, ease of use and
efficiency of these classes of tools.

Section 5 presents guidelines for the selection of the most appropriate class
of anti-virus tools. It begins by outlining the important environmental aspects
that should be considered. Next, the information from Section 4 is summarized
and a variety of tables comparing and contrasting the various classes of tools
are presented. The remainder of the section provides several hypothetical user
scenarios. A battery of tools is suggested for each application.

Section 6 presents guidelines for the selection of the best tool from within a
particular class. Important features that may distinguish products from others
within a particular class are highlighted.

This document will be most useful if read in its entirety. However, the reader
may wish to skip the details on different tools found in Section 4 on an
initial reading. Section 5 may help the reader narrow the focus to specific
classes of tools for a specific environment. Then the reader may return to
Section 4 for details on those classes of tools.

1.3 Definitions and Basic Concepts

This section presents informal definitions and basic concepts that will be used
throughout the document. This is intended to clarify the meaning of certain
terms which are used inconsistently in the virus field. However, this section
is not intended as a primer on viruses. Additional background information and
an extensive "Suggested Reading" list may be found in NIST Special
Publication 500-166.

A virus is a self-replicating code segment which must be attached to a host
executable. (1) When the host is executed, the virus code also executes. If
possible, the virus will replicate by attaching a copy of itself to another
executable. The virus may include an additional "payload" that triggers when
specific conditions are met. For example, some viruses display a message on a
particular date.

footnote (1): An executable is an abstraction for programs, command files and
other objects on a computer system that can be executed. On a DOS PC, for
example, this would include batch command files, COM files, EXE-format files
and boot sectors of disks.

A Trojan horse is a program that performs a desired task, but also includes
unexpected (and undesirable) functions. In this respect, a Trojan horse is
similar to a virus, except a Trojan horse does not replicate. An example of a
Trojan horse would be an editing program for a multi-user system which has been
modified to randomly delete one of the user's files each time that program is
used. The program would perform its normal, expected function (editing), but
the deletions are unexpected and undesired. A host program that has been
infected by a virus is often described as a Trojan horse. However, for the
purposes of this document, the term Trojan horse will exclude virus-infected
programs.

A worm is a self-replicating program. It is self-contained and does not require
a host program. The program creates the copy and causes it to execute; no user
intervention is required. Worms commonly utilize network services to propagate
to other computer systems.

A variant is a virus that is generated by modifying a known virus. Examples are
modifications that add functionality or evade detection. The term variant is
usually applied only when the modifications are minor in nature. An example
would be changing the trigger date from Friday the 13th to Thursday the 12th.

An overwriting virus will destroy code or data in the host program by replacing
it with the virus code. It should be noted that most viruses attempt to retain
the original host program's code and functionality after infection because the
virus is more likely to be detected and deleted if the program ceases to work.
A non-overwriting virus is designed to append the virus code to the physical
end of the program or to move the original code to another location.

A self-recognition procedure is a technique whereby a virus determines whether
or not an executable is already infected. The procedure usually involves
searching for a particular value at a known position in the executable.
Self-recognition is required if the virus is to avoid multiple infections of a
single executable. Multiple infections cause excessive growth in size of
infected executables and corresponding excessive storage space, contributing to
the detection of the virus.

A resident virus installs itself as part of the operating system upon execution
of an infected host program. The virus will remain resident until the system is
shut down. Once installed in memory, a resident virus is available to infect
all suitable hosts that are accessed.

A stealth virus is a resident virus that attempts to evade detection by
concealing its presence in infected files. To achieve this, the virus
intercepts system calls which examine the contents or attributes of infected
files. The results of these calls must be altered to correspond to the file's
original state. For example, a stealth virus might remove the virus code from
an executable when it is read (rather than executed) so that an anti-virus
software package will examine the original, uninfected host program.

An encrypted virus has two parts: a small decryptor and the encrypted virus
body. When the virus is executed, the decryptor will execute first and decrypt
the virus body. Then the virus body can execute, replicating or becoming
resident. The virus body will include an encryptor to apply during replication.
A variably encrypted virus will use different encryption keys or encryption
algorithms. Encrypted viruses are more difficult to disassemble and study since
the researcher must decrypt the code.

A polymorphic virus creates copies during replication that are functionally
equivalent but have distinctly different byte streams. To achieve this, the
virus may randomly insert superfluous instructions, interchange the order of
independent instructions, or choose from a number of different encryption
schemes. This variable quality makes the virus difficult to locate, identify,
or remove.

A research virus is one that has been written, but has never been unleashed on
the public. These include the samples that have been sent to researchers by
virus writers. Viruses that have been seen outside the research community are
termed "in the wild."

It is difficult to determine how many viruses exist. Polymorphic viruses and
minor variants complicate the equation. Researchers often cannot agree whether
two infected samples are infected with the same virus or different viruses. We
will consider two viruses to be different if they could not have evolved from
the same sample without a hardware error or human modification.






2.0 Functionality

Anti-virus tools perform three basic functions. Tools may be be used to detect,
identify, or remove viruses.(2) Detection tools perform proactive detection,
active detection, or reactive detection. That is, they detect a virus before it
executes, during execution, or after execution. Identification and removal
tools are more straightforward in their application; neither is of use until a
virus has been detected.

footnote (2): A few tools are designed to prevent infection by one or more
viruses. The discussion of these tools is limited to Section 4.7.2, Inoculation,
due to their limited application.

2.1 Detection Tools

Detection tools detect the existence of a virus on a system. These tools
perform detection at a variety of points in the system. The virus may be
actively executing, residing in memory, or stored in executable code. The virus
may be detected before execution, during execution, or after execution and
replication.

2.1.1 Detection by Static Analysis

Static analysis detection tools examine executables without executing them.
Such tools can be used in proactive or reactive fashion. They can be used to
detect infected code before it is introduced to a system by testing all
diskettes before installing software on a system. They can also be used in a
more reactive fashion, testing a system on a regular basis to detect any
viruses acquired between detection phases.

2.1.2 Detection by Interception

To propagate, a virus must infect other host programs. Some detection tools are
intended to intercept attempts to perform such "illicit" activities. These
tools halt the execution of virus-infected programs as the virus attempts to
replicate or become resident. Note that the virus has been introduced to the
system and attempts to replicate before detection can occur.



2.1.3 Detection of Modification

All viruses cause modification of executables in their replication process. As
a result, the presence of viruses can also be detected by searching for the
unexpected modification of executables. This process is sometimes called
integrity checking .

Detection of modification may also identify other security problems, such as
the installation of Trojan horses. Note that this type of detection tool works
only after infected executables have been introduced to the system and the
virus has replicated.

2.2 Identification Tools

Identification tools are used to identify which virus has infected a particular
executable. This allows the user to obtain additional information about the
virus. This is a useful practice, since it may provide clues about other types
of damage incurred and appropriate clean-up procedures.

2.3 Removal Tools

In many cases, once a virus has been detected it is found on numerous systems
or in numerous executables on a single system. Recovery from original diskettes
or clean backups can be a tedious process. Removal tools attempt to efficiently
restore the system to its uninfected state by removing the virus code from the
infected executable.






3.0 Selection Factors

Once the functional requirements have been determined, there will still be a
large assortment of tools to choose from. There are several important selection
factors that should be considered to ensure that the right tool is selected for
a particular environment.

There are four critical selection factors: Accuracy, Ease of Use,
Administrative Overhead and System Overhead. Accuracy describes the tool's
relative success rate and the types of errors it can make. Ease of use
describes the typical user's ability to install and execute the tool and
interpret the results. Administrative overhead is the measure of technical
support and distribution effort required. System overhead describes the tool's
impact on system performance. These factors are introduced below. In depth
discussions of these factors are in subsequent subsections.

Accuracy is the most important of the selection factors. Errors in detecting,
identifying or removing viruses undermine user confidence in a tool, and often
cause users to disregard virus warnings. Errors will at best result in loss of
time; at worst they will result in damage to data and programs.

Ease of use is concerned with matching the background and abilities of the
system's user to the appropriate software. This is also important since
computer users vary greatly in technical skills and ability.

Administrative overhead can be very important as well. Distribution of updates
can be a time-consuming task in a large organization. Certain tools require
maintenance by the technical support staff rather than the end-user. End-users
will require assistance to interpret results from some tools; this can place a
large burden on an organization's support staff. It is important to choose
tools that your organization has the resources to support.

System overhead is inconsequential from a strict security point of view.
Accurate detection, identification or removal of the virus is the important
point. However, most of these tools are intended for end-users. If a tool is
slow or causes other applications to stop working, end-users will disable it.
Thus, attention needs to be paid to the tool's ability to work quickly and to
co-exist with other applications on the computer.

3.1 Accuracy

Accuracy is extremely important in the use of all anti-virus tools.
Unfortunately, all anti-virus tools make errors. It is the type of errors and
frequency with which they occur that is important. Different errors may be
crucial in different user scenarios.

Computer users are distributed over a wide spectrum of system knowledge. For
those users with the system knowledge to independently verify the information
supplied by an anti-virus tool, accuracy is not as great a concern.
Unfortunately, many computer users are not prepared for such actions. For such
users, a virus infection is somewhat frightening and very confusing. If the
anti-virus tool is supplying false information, this will make a bad situation
worse. For these users, the overall error rate is most critical.

3.1.1 Detection Tools

Detection tools are expected to identify all executables on a system that have
been infected by a virus. This task is complicated by the release of new
viruses and the continuing invention of new infection techniques. As a result,
the detection process can result in errors of two types: false positives and
false negatives.

When a detection tool identifies an uninfected executable as host to a virus,
this is known as a false positive (this is also known as a Type I error.) In
such cases, a user will waste time and effort in unnecessary cleanup
procedures. A user may replace the executable with the original only to find
that the executable continues to be identified as infected. This will confuse
the user and result in a loss of confidence in either the detection procedures
or the tool vendor. If a user attempts to "disinfect" the executable, the
removal program may abort without changing the executable or will irreparably
damage the program by removing useful code. Either scenario results once more
in confusion for the user and lost confidence.

When a detection tool examines an infected executable and incorrectly proclaims
it to be free of viruses, this is known as a false negative, or Type II error.
The detection tool has failed to alert the user to the problem. This kind of
error leads to a false sense of security for the user and potential disaster.

3.1.2 Identification Tools

Identification tools identify which virus has infected a particular executable.
Defining failure in this process turns out to be easier than success. The
identification tool has failed if it cannot assign a name to the virus or
assigns the wrong name to the virus.

Determining if a tool has correctly named a virus should be a simple task, but
in fact it is not. There is disagreement even within the anti-virus research
community as to what constitutes "different" viruses. As a result, the
community has been unable to agree on the number of existing viruses, and the
names attached to them have only vague significance. This leads to a question
of precision.

As an example, consider two PC virus identification tools. The first tool
considers the set of PC viruses as 350 distinct viruses. The second considers
the same set to have 900 members. This occurs because the first tool groups a
large number of variants under a single name. The second tool will name viruses
with greater precision (i.e., viruses grouped together by the first tool are
uniquely named by the second).

Such precision problems can occur even if the vendor attempts to name with high
precision. A tool may misidentify a virus as another variant of that virus for
a variety of reasons. The variant may be new, or analysis of samples may have
been incomplete. The loss of precision occurs for different reasons, but the
results are no different from the previous example. Any "successful" naming
of a virus must be considered along with the degree of precision.

3.1.3 Removal Tools

Removal tools attempt to restore the infected executables to their uninfected
state. Removal is successful if the executable, after disinfection, matches the
executable before infection on a byte-for-byte basis. The removal process can
also produce two types of failures: hard failure and soft failure.

A hard failure occurs if the disinfected program will no longer execute or the
removal program terminates without removing the virus. Such a severe failure
will be obvious to detect and can occur for a variety of reasons. Executables
infected by overwriting viruses cannot be recovered in an automated fashion;
too much information has been lost. Hard failures also occur if the removal
program attempts to remove a different virus than the actual infector.

Removal results in a soft failure if the process produces an executable, which
is slightly modified from its original form, that can still execute. This
modified executable may never have any problems, but the user cannot be certain
of that. The soft failure is more insidious, since it cannot be detected by the
user without performing an integrity check.

3.2 Ease of Use

This factor focuses on the level of difficulty presented to the end-user in
using the system with anti-virus tools installed. This is intended to gauge the
difficulty for the system user to utilize and correctly interpret the feedback
received from the tool. This also measures the increased difficulty (if any) in
fulfilling the end-user's job requirements.

Ease of Use is the combination of utilization and interpretation of results.
This is a function of tool design and quality of documentation. Some classes of
tools are inherently more difficult to use. For example, installation of the
hardware component of a tool requires greater knowledge of the current hardware
configuration than a comparable software-only tool.

3.3 Administrative Overhead

This factor focuses on the difficulty of administration of anti-virus tools. It
is intended to gauge the workload imposed upon the technical support team in an
organization.

This factor considers difficulty of installation, update requirements, and
support levels required by end-users. These functions are often the
responsibility of technical support staff or system administrators rather than
the end-user. Note that an end-user without technical support must perform all
of these functions himself.

3.4 System Overhead

System overhead measures the overall impact of the tool upon system
performance. The relevant factors will be the raw speed of the tool and the
procedures required for effective use. That is, a program that is executed
every week will have a lower overall impact than a program that runs in the
background at all times.

4.0 Tools and Techniques

There is a wide variety of tools and techniques which can be applied to the
anti-virus effort. This section will address the following anti-virus
techniques:

    o signature scanning and algorithmic detection
    o general purpose monitors
    o access control shells
    o checksums  for change detection
    o knowledge-based removal tools
    o research efforts
        - heuristic binary analysis
        - precise identification
    o other tools
        - system utilities as removal tools
        - inoculation



For detection of viruses, there are five classes of techniques: signature
scanning and algorithmic detection; general purpose monitors; access control
shells; checksums for change detection; and heuristic binary analysis. For
identification of viruses, there are two techniques: scanning and algorithmic
detection; and precise identification tools. Finally, removal tools are
addressed. Removal tools come in three forms: general system utilities,
single-virus disinfectors, and general disinfecting programs.

4.1 Signature Scanning and Algorithmic Detection

A common class of anti-virus tools employs the complementary techniques of
signature scanning and algorithmic detection. This class of tools is known as
scanners , which are static analysis detection tools (i.e., they help detect
the presence of a virus). Scanners also perform a more limited role as
identification tools (i.e., they help determine the specific virus detected).
They are primarily used to detect if an executable contains virus code, but
they can also be used to detect resident viruses by scanning memory instead of
executables.

They may be employed proactively or reactively. Proactive application of
scanners is achieved by scanning all executables introduced to the system.
Reactive application requires scanning the system at regular intervals (e.g.,
weekly or monthly).

4.1.1 Functionality

Scanners are limited intrinsically to the detection of known viruses. However,
as a side effect of the basic technique, some new variants may also be
detected. They are also identification tools, although the methodology is
imprecise.

Scanners examine executables (e.g., .EXE or .COM files on a DOS system) for
indications of infection by known viruses. Detection of a virus produces a
warning message. The warning message will identify the executable and name the
virus or virus family with which it is infected. Detection is usually performed
by signature matching; special cases may be checked by algorithmic methods.

In signature scanning an executable is searched for selected binary code
sequences, called a virus signature, which are unique to a particular virus, or
a family of viruses. The virus signatures are generated by examining samples of
the virus. Additionally, signature strings often contain wild cards to allow
for maximum flexibility.

Single-point scanners add the concept of relative position to the virus
signature. Here the code sequence is expected at a particular position within
the file. It may not even be detected if the position is wrong. By combining
relative position with the signature string, the chances of false positives is
greatly reduced. As a result, these scanners can be more accurate than blind
scanning without position.

Polymorphic viruses , such as those derived from the MtE (mutation engine)
[Sku92] , do not have fixed signatures. These viruses are self-modifying or
variably encrypted. While some scanners use multiple signatures to describe
possible infections by these viruses, algorithmic detection is a more powerful
and more comprehensive approach for these difficult viruses.

4.1.2 Selection Factors

Accuracy

Scanners are very reliable for identifying infections of viruses that have been
around for some time. The vendor has had sufficient time to select a good
signature or develop a detection algorithm for these well-known viruses. For
such viruses, a detection failure is unlikely with a scanner. An up-to-date
scanner tool should detect and to some extent identify any virus you are likely
to encounter. Scanners have other problems, though. In the detection process,
both false positives and false negatives can occur.

False positives occur when an uninfected executable includes a byte string
matching a virus signature in the scanner's database. Scanner developers test
their signatures against libraries of commonly-used, uninfected software to
reduce false positives. For additional assurance, some developers perform
statistical analysis of the likelihood of code sequences appearing in
legitimate programs. Still, it is impossible to rule out false positives.
Signatures are simply program segments; therefore, the code could appear in an
uninfected program.

False negatives occur when an infected executable is encountered but no pattern
match is detected. This usually results from procedural problems; if a stealth
virus is memory-resident at the time the scanner executes, the virus may hide
itself. False negatives can also occur when the system has been infected by a
virus that was unknown at the time the scanner was built.

Scanners are also prone to misidentification or may lack precision in naming.
Misidentification will usually occur when a new variant of an older virus is
encountered. As an example, a scanner may proclaim that Jerusalem-B has been
detected, when in fact the Jerusalem-Groen Links virus is present. This can
occur because these viruses are both Jerusalem variants and share much of their
code. Another scanner might simply declare "Jerusalem variant found in
filename." This is accurate, but rather imprecise.

Ease of Use

Scanners are very easy to use in general. You simply execute the scanner and it
provides concise results. The scanner may have a few options describing which
disk, files, or directories to scan, but the user does not have to be a
computer expert to select the right parameters or comprehend the results.

Administrative Overhead

New viruses are discovered every week. As a result, virus scanners are
immediately out of date. If an organization distributes scanners to its users
for virus detection, procedures must be devised for distribution of updates. A
scanner for a DOS PC that is more than a few months old will not detect most
newly developed viruses. (It may detect, but misidentify, some new variants.)
Timely updates are crucial to the effectiveness of any scanner-based anti-virus
solution. This can present a distribution problem for a large organization.

Installation is generally simple enough for any user to perform. Interpreting
the results is very simple when viruses are correctly identified. Handling
false positives will usually require some assistance from technical support.
This level of support may be available from the vendor.

Efficiency

Scanners are very efficient. There is a large body of knowledge about searching
algorithms, so the typical scanner executes very rapidly. Proactive application
will generally result in higher system overhead.

4.1.3 Summary

Scanners are extremely effective at detecting known viruses. Scanners
are not intended to detect new viruses (i.e., any virus discovered after the
program was released) and any such detection will result in misidentification.
Scanners enjoy an especially high level of user acceptance because they name
the virus or virus family. However, this can be undermined by the occurrence of
false positives.

The strength of a scanner is highly dependent upon the quality and timeliness
of the signature database. For viruses requiring algorithmic methods, the
quality of the algorithms used will be crucial.

The major strengths of scanners are:

 Up-to-date scanners can be used to reliably detect more than 95 percent
of all virus infections at any given time. Scanners identify both the infected
executable and the virus that has infected it. This can speed the recovery
process. Scanners are an established technology, utilizing highly efficient
algorithms. Effective use of scanners usually does not require any special
knowledge of the computer system.



The major limitations of scanners are:

 A scanners only looks for viruses that were known at the time its
database of signatures was developed. As a result, scanners are prone to false
negatives. The user interprets "No virus detected" as "No virus exists.''
These are not equivalent statements. Scanners must be updated regularly to
remain effective. Distribution of updates can be a difficult and time-consuming
process. Scanners do not perform precise identification. As a result, they are
prone to false positives and misidentification.



4.2 General Purpose Monitors

General purpose monitors protect a system from the replication of viruses or
execution of the payload of Trojan horses by actively intercepting malicious
actions.

4.2.1 Functionality

Monitoring programs are active tools for the real-time detection of viruses and
Trojan horses. These tools are intended to intervene or sound an alarm every
time a software package performs some suspicious action considered to be
virus-like or otherwise malicious behavior. However, since a virus is a code
stream, there is a very real possibility that legitimate programs will perform
the same actions, causing the alarms to sound.

The designer of such a system begins with a model of "malicious" behavior,
then builds modules which intercept and halt attempts to perform those actions.
Those modules operate as a part of the operating system.

4.2.2 Selection Factors

Accuracy

A monitoring program assumes that viruses perform actions that are in its model
of suspicious behavior and in a way that it can detect. These are not always
valid assumptions. New viruses may utilize new methods which may fall outside
of the model. Such a virus would not be detected by the monitoring program.

The techniques used by monitoring tools to detect virus-like behavior are also
not fool-proof. Personal computers lack memory protection, so a program can
usually circumvent any control feature of the operating system. As a part of
the operating system, monitoring programs are vulnerable to this as well. There
are some viruses which evade or turn off monitoring programs.

Finally, legitimate programs may perform actions that the monitor deems
suspicious (e.g., self-modifying programs).

Ease of Use

Monitoring software is not appropriate for the average user. The monitor may be
difficult to configure properly. The rate of false alarms can be high,
particularly false positives, if the configuration is not optimal.

The average user may not be able to determine that program A should modify
files, but program B should not. The high rate of false alarms can discourage
such a user. At worst, the monitor will be turned off or ignored altogether.



Administrative Overhead

Monitoring programs can impose a fairly heavy administrative workload. They
impose a moderate degree of overhead at installation time; this is especially
true if several different systems are to be protected. The greatest amount of
overhead will probably result from false positives, though. This will vary
greatly according to the users' level of expertise.

On the other hand, the monitoring software does not have to be updated
frequently. It is not virus-specific, so it will not require updating until new
virus techniques are devised. (It is still important to remain up-to-date; each
time a new class of virus technology is developed, a number of variations
emerge.)

Efficiency

Monitoring packages are integrated with the operating system so that additional
security procedures are performed. This implies some amount of overhead when
any program is executed. The overhead is usually minimal, though.

4.2.3 Summary

Monitoring software may be difficult to use but may detect some new
viruses that scanning does not detect, especially if they do not use new
techniques.

These monitors produce a high rate of false positives. The users of these
programs should be equipped to sort out these false positives on their own.
Otherwise, the support staff will be severely taxed.

Monitors can also produce false negatives if the virus doesn't perform any
activities the monitor deems suspicious. Worse yet, some viruses have succeeded
in attacking monitored systems by turning off the monitors themselves.

4.3 Access Control Shells

Access control shells function as part of the operating system, much like
monitoring tools. Rather than monitoring for virus-like behavior, the shell
attempts to enforce an access control policy for the system. This policy is
described in terms of programs and the data files they may access. The access
control shell will sound an alarm every time a user attempts to access or
modify a file with an unauthorized software package.

4.3.1 Functionality

To perform this process, the shell must have access to identification and
authentication information. If the system does not provide that information,
the access control shell may include it. The access control shell may also
include encryption tools. These tools can be used to ensure that a user does
not reboot from another version of the operating system to circumvent the
controls. Note that may of these tools require additional hardware to
accomplish these functions.

Access control shells are policy enforcement tools. As a side benefit, they can
perform real-time detection of viruses and Trojan horses. The administrator of
such a system begins with a description of authorized system use, then converts
that description into a set of critical files and the programs which may be
used to modify them. The administrator must also select the files which require
encryption.

For instance, a shipping clerk might be authorized to access the inventory
database with a particular program. However, that same clerk may not be allowed
to access the database directly with the database management software. The
clerk may not be authorized to access the audit records generated by the
trusted application with any program. The administrator would supply
appropriate access control statements as input to the monitor and might also
encrypt the database.

4.3.2 Selection Factors

Accuracy

Access control shells, like monitoring tools, depend upon the virus or Trojan
horse working in an expected manner. On personal computer systems, this is not
always a valid assumption. If the virus uses methods that the access control
shell does not monitor, the monitor will produce false negatives.

Even with the access control shell, a well-behaved virus can modify any program
that its host program is authorized to modify. To reduce the overhead, many
programs will not be specifically constrained. This will allow a virus to
replicate and is another source of false negatives.

False positives can also occur with access control shells. The system
administrator must have sufficient familiarity with the software to authorize
access to every file the software needs. If not, legitimate accesses will cause
false alarms. If the system is stable, such false positives should not occur
after an initial debugging period.

Ease of Use

These tools are intended for highly constrained environments. They usually are
not appropriate for the average user at home. They can also place a great deal
of overhead on system administrators. The access control tables must be rebuilt
each time software or hardware is added to a system, job descriptions are
altered, or security policies are modified. If the organization tends to be
dynamic, such a tool will be very difficult to maintain. Organizations with
well-defined security policies and consistent operations may find maintenance
quite tolerable.

This software is easy for users, though. They simply log in and execute
whatever programs they require against the required data. If the access control
shell prevents the operation, they must go through the administrator to obtain
additional privileges.

Efficiency

An access control shell modifies the operating system so that additional
security procedures are performed. This implies some amount of overhead when
any program is executed. That overhead may be substantial if large amounts of
data must be decrypted and re-encrypted upon each access.

Administrative Overhead

An access control shell should not require frequent updates. The software is
not specific to any particular threat, so the system will not require updates
until new techniques are devised for malicious code. On the other hand, the
access control tables which drive the software may require frequent updates.

4.3.3 Summary

Access control shells may be difficult to administer, but are
relatively easy for the end-user. This type of tool is primarily designed for
policy enforcement, but can also detect the replication of a virus or
activation of a Trojan horse.

The tool may incur high overhead processing costs or be expensive due to
hardware components. Both false positives and false negatives may occur. False
positives will occur when the access tables do not accurately reflect system
processing requirements. False negatives will occur when virus replication does
not conflict with the user's access table entries.

4.4 Checksums for Change Detection

Change detection is a powerful technique for the detection of viruses and
Trojan horses. Change detection works on the theory that executables are static
objects; therefore, modification of an executable implies a possible virus
infection. The theory has a basic flaw: some executables are self-modifying.
Additionally, in a software development environment, executables may be
modified by recompilation. These are two examples where checksumming may be an
inappropriate solution to the virus problem.

4.4.1 Functionality

Change detection programs generally use an executable as the input to a
mathematical function, producing a checksum. The change detection program is
executed once on the (theoretically) clean system to provide a baseline(3)
for testing. During subsequent executions, the program compares the computed
checksum with the baseline checksum. A change in the checksum indicates a
modification of the executable.

footnote (3): The original file names and their corresponding checksums.

Change detection tools are reactive virus detection tools. They can be used to
detect any virus, since they look for modifications in executables. This is a
requirement for any virus to replicate. As long as the change detector reviews
every executable in its entirety on the system and is used in a proper manner,
a virus cannot escape detection.

Change detection tools employ two basic mathematical techniques: Cyclic
Redundancy Checks (CRC) and cryptographic checksums .

CRC-Codings

CRC checksums are commonly used to verify integrity of packets in networks and
other types of communications between computers. They are fairly efficient and
well understood. CRC-based checksums are not extremely secure; they are based
on a known set of algorithms. Therefore they can be broken (the particular
algorithm can be guessed) by a program if it can find the checksum for a file.

CRC checksum tools, like all change detection tools, can only detect that a
virus has replicated. Additionally, the executable must be appear in the
baseline.

Cryptographic Checksums

Cryptographic checksums are obtained by applying cryptographic algorithms to
the data. Both public and private key algorithms can be used. In general,
private key algorithms are used for efficiency. These techniques are sometimes
used in conjunction with two other procedures to decrease system overhead.
These techniques are message digesting and hashing.(4)

footnote (4): Discussion of cryptographic terminology is beyond the scope of
this document. Please see [Sim92].

In Message Digesting , hashing is used in conjunction with cryptographic
checksums. The hash function, which is very fast, is applied directly to the
executable. The result is much smaller than the original data. The checksum is
computed by applying the cryptographic function to the hash result. The final
result approaches the cryptographic checksum for security, but is much more
efficient.

4.4.2 Selection Factors

Accuracy

Properly implemented and used, change detection programs should detect every
virus. That is, there are no false negatives with change detection. Change
detection can result in high numbers of false positives, however. Programs tend
to store configuration information in files containing executable code. If
these files are checksummed, as they should be, a change in configuration will
trigger the change detector. Additionally, the system must be virus-free when
the checksums are calculated; resident viruses may fool the change detection
software.



Ease of Use

Change detection software is more challenging to use than some other anti-virus
tools. It requires good security procedures and substantial knowledge of the
computer system. Procedurally, it is important to protect the baseline. The
checksums should be stored off-line or encrypted. Manipulation of the baseline
will make the system appear to have been attacked.

Analysis of the results of a checksumming procedure is also more difficult. The
average user may not be able to determine that one executable is self-modifying
but another is not. False positives due to self-modifying code can discourage
such a user, until the output of the change detector is ignored altogether.

Administrative Overhead

Change detection software is easy to install and it requires no updates. The
baseline must be established by a qualified staff member. This includes the
initial baseline, as well as changes to the baseline as programs are added to
the system. Once in operation, a high degree of support can be required for the
average end-user, however. A qualified staff member must be available to
determine whether or not a change to a particular executable is due to a virus
or simply a result of self-modification.

Efficiency

Change detectors do not impose any overhead on general system use. There is,
however, some storage overhead for the baseline checksums. These are best
stored off-line with the checksum program.

The calculation of checksums is computationally intensive; the mathematical
functions must be calculated on at least a portion of the executable. To be
exhaustive, the function should be calculated on the entire executable.

4.4.3 Summary

If change is detected, there are several possibilities: a virus infection,
self-modification, recompilation, or modification of the baseline. A
knowledgeable user is required to determine the specific reason for change.

The primary strength of change detection techniques is the ability to detect
new viruses and Trojan horses. The limitation of change detection is the need
for a knowledgeable user to interpret the output.

4.5 Knowledge-Based Virus Removal Tools

The primary means of automated removal of virus infection is knowledge-based
removal tools. These removal tools attempt to reverse the modifications a virus
makes to a file. After analyzing a particular virus to determine its effects on
an infected file, a suitable algorithm is developed for disinfecting files.
Tools are available which address only a single virus. These single virus
disinfectors are usually developed as the result of a particularly virulent
outbreak of a virus. Others detectors are general virus removal programs,
containing removal algorithms for several viruses.

4.5.1 Functionality

Knowledge-based removal tools restore an executable to its pre-infection state.
All modifications to the original executable must be known in order to
accomplish this task. For example, if a file is infected with an overwritting
virus, removal is not possible. The information that was overwritten cannot be
restored.



The most critical piece of information in the removal process is the identity
of the virus itself. If the removal program is removing Jerusalem-DC, but the
host is infected with Jerusalem-E2, the process could fail. Unfortunately, this
information is often unavailable or imprecise. This is why precise
identification tools are needed.

4.5.2 Selection Factors

Disinfecting software is not very accurate, for a variety of reasons. The error
rates are fairly high; however, most are soft errors. This is a result of
incomplete information regarding the virus and the lack of quality assurance
among virus writers. Additionally, removal techniques tend to fail when a
system or file has been infected multiple times (i.e., by the same virus more
than once, or by more than one virus).

These programs are relatively easy to use and can disinfect large numbers of
programs in a very short time. Any system overhead is inconsequential since the
system should not be used until the virus is removed.

4.5.3 Summary

Accurate removal may not be possible. Even if it is theoretically possible,
precise identification of the virus is necessary to ensure that the correct
removal algorithm is used.

Certain viruses (e.g., overwriting viruses) always cause irreparable damage to
an executable. Some extraordinarily well-behaved viruses can be disinfected
every time. Most viruses fall somewhere in between. Disinfection will often
work, but the results are unpredictable.

Some executables cannot be recovered to the exact pre-infection state. In such
a case, the file length or checksum of the disinfected executable may differ
from the pre-infection state. In such a case, it is impossible to predict the
behavior of the disinfected program. This is the reason virus researchers
generally dislike removal programs and discourage their use.

4.6 Research Efforts

The following subsections describe research areas in the anti-virus field. New
tools, based on techniques developed in these and other areas, may be available
in the near future.

4.6.1 Heuristic Binary Analysis

Static analysis detection tools, based upon heuristic binary analysis, are a
focus of research at this time. Heuristic binary analysis is a method whereby
the analyzer traces through an executable looking for suspicious, virus-like
behavior. If the program appears to perform virus-like actions, a warning is
displayed.

Functionality

Binary analysis tools examine an executable for virus-like code. If the code
utilizes techniques which are common to viruses, but odd for legitimate
programs, the executable is flagged as "possibly infected." Examples include
self-encrypted code or code that appears to have been appended to an existing
program.

Selection Factors

Both false positives and negatives are sure to result with use of this type of
software. False positives occur when an uninfected program uses techniques
common to viruses but uncommon in legitimate programs. False negatives will
occur when virus code avoids use of those techniques common to viruses.

Binary analysis tools are fairly easy to use. The user simply specifies a
program or directory to be analyzed. Analyzing the results is more difficult.
Sorting out the false positives from real infections may require more knowledge
and experience than the average user possesses.

Heuristic analysis is more computationally intensive than other static analysis
methods. This method would be inappropriate for daily use on a large number of
files. It is more appropriate for one-time use on a small number of files, as
in acceptance testing.

A heuristic analysis program will require updates as new techniques are
implemented by virus writers.



Summary

Early examples of this class of tool appear to have fairly high error rates as
compared with commercial detection software. As with system monitors, it is
difficult to define suspicious in a way that prevents false positives and false
negatives. However, these types of tools have been used successfully to
identify executables infected by "new" viruses in a few actual outbreaks.

Heuristic binary analysis is still experimental in nature. Initial results have
been sufficiently encouraging to suggest that software acceptance procedures
could include these tools to augment more traditional technology.

4.6.2 Precise Identification Tools

Precise identification tools are a means by which viruses are named with a much
higher degree of assurance. These tools are intended to augment detection
tools. Once a virus has been detected, a precise identification tool would be
invoked in order to more accurately identify the virus.

Functionality

Virus scanners, currently the most common virus detection method, generally
employ signature scanning to detect and identify viruses. This method, however,
can lead to misidentifications. The signature that the scanner matched could
appear in more than one variant of the virus. To avoid mis-identification the
whole virus must match, not just a subset of the virus (i.e., the signature).
It is neither feasible nor desirable for identification software to be
distributed containing the code to all viruses it can detect. Therefore,
prototype precise identification tools utilize a "virus map" to represent the
contents of the virus. The virus map contains checksum values for all constant
parts of the virus code. The map skips over sections of the virus that contain
variable information such as text or system dependent data values.

If the checksums generated by the corresponding portions of the program match,
the program is almost certainly infected by the virus corresponding to the map.
If none of the maps in the database correspond, the program is infected by a
new virus (or is uninfected.)

Selection Factors

The quality of the results produced by a precise identification tool is
dependent upon the quality of the virus map database. If that has been done
well and kept current, these tools are extremely accurate and precise when
identifying known viruses. Conversely, if the virus is new or has no
corresponding entry in the database, the precise identification tool should
always "fail" to identify the viruses.

This type of tool is easy to use. The user simply specifies an executable, and
the tool returns a name, if known. The results are straightforward; it is virus
"X," or unknown.

Precise identification tools are slow due to the intensive nature of the
computations. These tools may be used to perform an identification pass after
the use of a more efficient detection tool. Such a plan would provide the user
with the benefits of precise identification without great overhead. Once a
virus has been detected, the user wants to know exactly what virus he has and
time is not a significant factor.



Summary

Users want to know more about the virus infecting their systems. Precise
identification will help them obtain more complete information and can also
facilitate automated removal.

Researchers will also wish to use this type of tool. It will allow them to
separate samples of known viruses from new ones without performing analysis.

4.7 Other Tools

The remaining tools, system utilities and inoculation, are included for
completeness. These tools can be used to provide some measure of functionality.
In general, however, these tools are weaker than general anti-virus tools.

4.7.1 System Utilities

Some viruses can be detected or removed with basic system utilities. (5)
For example, most DOS boot sector infectors and some Macintosh viruses can be
removed with system utilities. System utilities can also be used to detect
viruses by searching for virus signatures. These tools have a rather limited
focus, though.

footnote (5): Two examples of these system utilities are Norton Utilities for
the PC and ResEdit for the Macintosh.

Viruses that can be disinfected "by hand" are generally the extremely
well-behaved, highly predictable viruses that are well understood. Such viruses
are the exception, not the rule. There are many more viruses that cannot be
disinfected with these tools.

Where possible, disinfection with system utilities will produce dependable
results. A reasonable amount of knowledge is required about the computer system
and the virus itself, though. This technique can also be very laborious if a
large number of systems are infected.

System utilities are an inefficient means of detection. Generally, only one
signature can be handled at a time. This might be a useful technique if a
specific virus is to be detected.



Summary

Accurate removal by system utilities is frequently impossible. Certain classes
of viruses (e.g., overwriting viruses) always damage the executable beyond all
hope of repair. Others modify the executable in rather complicated ways. Only
viruses that are extremely well-behaved can be disinfected every time.
Similarly, detection with system utilities has limited application.

4.7.2 Inoculation



In some cases, an executable can be protected against a small number of viruses
by "inoculation." This technique involves attaching the self-recognition code
for the virus to the executable at the appropriate location.

Since viruses may place their self-recognition codes in overlapping locations,
the number of viruses that can be inoculated against simultaneously will be
small. To make matters worse, a common way to create a new variant is to change
the self-recognition code. Thus, this technique will often fail when tested by
minor variants of the viruses inoculated against.

Inoculation is no substitute for more robust anti-virus tools and procedures.
It might be useful, though, if an organization has had recurring infections
from a single virus. For example, after cleaning three or four outbreaks of a
particular virus from a network of PCs, inoculation might be considered as a
desperation measure.




5.0 Selecting Anti-Virus Techniques

The selection of the appropriate class of anti-virus tools requires answers to
the following set of questions:

    o What is the probability of a virus infection?
    o What are the consequences of a virus infection?
    o What is the skill level of the users in your organization?
    o What level of support is available to the end-user?


The first two questions address risk; security should always be commensurate
with need. The third and fourth questions address the limitations of the tools
and personnel. The answers will be different for each person or organization.

Every organization is at some risk of virus infection. Virus infections can
occur whenever electronic information is shared. Every organization shares
information in some way and is a potential victim of a virus infection. Most
organizations should have some tools available to detect such an infection.

Personal computer users may benefit from tools to identify viruses, since so
many viruses exist. Identification tools are not necessary where viruses are
few or only theoretically possible.

The use of removal tools is generally not required.(6)  It may be desirable in
situations where a single person or a small team is tasked with cleaning up
after an infection or where high connectivity can result in rapid spread of the
virus (such as networks).

footnote (6): Exceptions, such as the DIR-2 PC virus, may be extremely difficult
to remove without appropriate tools. In this case, the only alternative to
removal tools is to format the disk.

5.1 Selecting Detection Tools

The first point to consider when selecting a detection product is the type of
viruses likely to be encountered. Approximately 95 percent of all virus
infections are accounted for by a small number of viruses. The viruses that
constitute this small set can vary geographically. The common viruses can be
distinct on different continents, due to the paths in which they travel. Of
course, different hardware platforms will be at risk from different viruses.

International organizations may be vulnerable to a larger set of viruses. This
set may be obtained by merging the sets of viruses from different geographical
regions where they do business. Organizations with contacts or installations in
locations where virus writers are particularly active [Bon91] are also more
likely to encounter new viruses.

Risk from new viruses is an important consideration. Scanners are limited by
their design to known viruses; other detection tools are designed to detect any
virus. If your organization is at high risk from new viruses, scanners should
not be the sole detection technique employed.

Another important criteria to consider is the number and type of errors
considered tolerable. The tolerance for a particular type of error in an
organization will vary according to the application. Table 1 shows the types of
errors which should be expected. An estimate of the frequency that this class
of error is encountered (Infrequent, Frequent, or Never) is also given for each
class of tools and error type. All anti-virus tools are subject to errors, but
their relative frequencies vary widely. Scanners probably have the lowest
overall error rate. Checksummers do not produce false negatives.











The third and fourth items to consider when selecting anti-virus tools are the
ease of use and administrative overhead required for each tool. Questions to
consider are:

What is the average skill level of your organization's end-user?
Does your organization have a support staff to assist user with more technical
problems?

Table 2 includes a general evaluation of the ease of use and administrative
overhead imposed by each class of tools.

If several tools still appear to be candidates, consider the functionality of
these tools beyond virus detection. Viruses are only one of the many threats to
computer security. All detection tools except scanners have general security
applications beyond viruses. Scanners are limited in application to viruses,
but have the added functionality of virus identification. (7) Consider the added
functionality which is most needed by your organization and choose accordingly.
The alternatives are outlined in table 3.

footnote (7) Some scanners can also detect known Trojan horses.

The final selection criteria to be considered is when does the tool detect
viruses. Proactive detection tools allow the user to keep viruses off a system
by testing incoming software. These tools only allow one chance of detecting a
virus (upon initial introduction to the system). Active detection tools
intervene during the replication phase itself. Reactive detection tools can be
used any time after a virus has entered the system. Additionally, reactive
tools are not as rigorous in their demands on system performance. Table 4 shows
when these different tools detect viruses.

5.1.1 Combining Detection Tools

The most complete protection will be obtained by combining tools which perform
in radically different fashion and protect against different classes of
viruses. For instance, when used together a scanner and a checksum program will
protect against both known and unknown viruses. The scanner can detect known
viruses before software is installed on the system. A virus can be modified to
elude the scanner, but it will be detected by the checksum program.

The two tools should have different "additional functionality" (see table )
to form the most comprehensive security package. For instance, the combination
of a checksum program and an access control shell would also detect Trojan
horses and enforce organizational security policy in addition to virus
detection. On the other hand, adding a binary analyzer to a system that already
employs checksumming would not provide additional functionality.

If you must use two scanners, be sure that they use different search strings. A
number of tools are based on published search strings; shareware tools commonly
utilize the same public domain signature databases. Two different scanner
engines looking for the same strings do not provide any additional protection
of information. (8)

footnote (8): Algorithms for detection tend to be independently developed.

5.2 Identification Tools

Currently, scanners are the only effective means of identifying viruses. As
discussed in Section , the accuracy to which scanners identify viruses can
vary. In the future, precise identification tools should offer greatly
increased accuracy.

5.3 Removal Tools

The most dependable technique for virus removal continues to be deletion of the
infected executable and restoration from a clean backup. If backups are
performed regularly and in a proper manner, virus removal tools may be
neglected.

In large organizations with high connectivity, automated removal tools should
be obtained. Virus eradication through the removal of infected executables may
require too much time and effort. Knowledge based tools will disinfect the
largest number of different viruses, but proper identification of the virus
prior to disinfection is critical. Even with knowledge based removal tools,
disinfection of executables is not always reliable (see Sec. ). Test all
disinfected executables to be sure they appear to execute properly. There is
still a chance, however, that soft errors will occur.

5.4 Example Applications of Anti-Virus Tools

This section provides hypothetical scenarios for the use of anti-virus tools.
For each application, a battery of tools is suggested. There are several ways
these tools can be applied to the same scenario; this text represents just one
set of rational solutions.

5.4.1 Average End-User

Detailed knowledge of the computer system is not required for the average
end-user to perform one's job. Such a user should not be required to obtain
detailed knowledge just to use anti-virus tools. This implies that scanners are
probably most appropriate for the average end-users. Any other choice will
require support from a technical support team or computer security incident
response team. Of the remaining tools, the best option is a checksum program.
By executing the checksum program regularly, for example weekly or monthly,
infections will be detected within a limited timeframe.



Another possibility is to relieve these users of the responsibility of
detecting viruses entirely. If a technical support team is already providing
other regular services (e.g., backup), the support team can use any combination
of anti-virus tools deemed necessary.

5.4.2 Power Users

Power users, those with detailed knowledge of their computer systems, will be
better equipped to handle a larger variety of anti-virus tools. A power user is
more able to determine whether a change detected by a checksum program is in
fact legitimate. Additionally, a power user is going to be better equipped to
configure some of the other tools, such as general purpose monitors and access
control shells.

5.4.3 Constrained User

If the user is constrained by policy to run a small set of programs against a
known set of data files, an access control shell may be the appropriate choice.
As an example, consider a data entry clerk who is permitted to run one
particular database application and a basic set of utilities: mail, word
processing, and a calendar program. An access control shell can be configured
so that any changes to executable files by that user are deemed illegal
operations. Additionally, if the set of executable files is restricted for the
user, it is difficult to introduce a virus into the system. The virus is unable
to spread if it can never be executed.

5.4.4 Acceptance Testing

Acceptance testing is a means by which software is verified to be
"virus-free" before it is put into daily use. This is usually accomplished by
placing the software on an isolated system and performing tests that are
intended to mimic every day use. A combination of anti-virus tools is required
to adequately perform this function, which must detect both known and future
viruses. In particular, a checksum program is most useful. Even if the trigger
conditions for the payload are not met, the virus will still most likely
attempt to replicate. It is the result of the replication process that a
checksum program detects.

5.4.5 Multi-User Systems

Although viruses found in the wild have been limited to personal computer
systems, viruses for multi-user systems have been demonstrated in a number of
laboratory experiments. Therefore, the potential exists for viruses on
multi-user systems. As a result, it is prudent to ensure that the security
measures taken on a multi-user system address viruses as well.

Currently, administrators of multi-user systems have a limited number of
options for virus protection. Administrators of these systems cannot use
monitors or scanners. Since there are no known viruses, there are no signatures
to search for or expected virus behavior to detect. An option that is available
to administrators of multi-user systems is change detection. Many of these
systems are already equipped with a checksum program. Access control shells are
another possibility for many systems. Like access control, though, they are not
usually designed for virus detection.



5.4.6 Network Server

Network servers present an interesting problem. They can support a wide variety
of machines, but may run an entirely different operating system. For instance,
a UNIX server may support a network of PC and Macintosh workstations.

The UNIX system cannot be infected by the Jerusalem-B or WDEF viruses, but
infected files may be stored on its disk. Once the network server has infected
files on it, the workstations it supports will rapidly become infected as well.

Since the viruses never execute on the server, the administrator is limited to
static detection techniques such as scanners or change detectors. The nature of
network servers allows these tools to be run automatically during off-peak
periods.






6.0  Selecting the Right Tool

Once an anti-virus technique has been selected, an appropriate tool from that
class must be selected. This section presents several features to be considered
when selecting a specific product from a class of tools.

6.1 Selecting a Scanner

Scanners are implemented in several forms. Hardware implementations, available
as add-on boards, scan all bus transfers. Software implementations include both
non-resident and resident software for the automatic scanning of diskettes.

Non-resident software is sufficiently flexible to meet most needs; however, to
be effective the user must execute the software regularly. Hardware or resident
software are better choices for enforcing security policy compliance. Resident
scanners may be susceptible to stealth viruses.

Although most scanners use similar detection techniques, notable differences
among products exist. Questions that potential users should consider when
selecting a scanner include:

  o    How frequently is the tool updated? A scanner must be updated regularly
    to remain effective. How frequently updates are needed depends on which
    platform the scanner is used. Update frequency should be proportional
    to the rate at which new viruses are discovered on that platform.
  o    Can the user add new signatures? This can be very important if a
    particularly harmful virus emerges between updates.
  o    Does the tool employ algorithmic detection? For which viruses does the
    tool use algorithmic detection? Algorithmic detection is preferable to
    the use of multiple signatures to detect polymorphic viruses.
  o    How efficient is the tool? Users are less likely to use a slow scanner.
    There can be a significant difference in performance between different
    search algorithms.
  o    Does the vendor develop their own virus signatures, or are the
    signatures based on published search strings? There is nothing
    particularly wrong with published search strings, but it indicates the
    level of resources the vendor has committed to the product.
  o    What is the level of documentation? Some packages arrive with large
    fact-filled binders; other packages are a single floppy disk with a few
    ASCII files describing installation and parameters.

6.2 Selecting a General Purpose Monitor

General purpose monitors are usually implemented in software; however, hardware
implementations do exist. Hardware versions may be more difficult to
circumvent, but they are not foolproof. The following questions should be
considered when selecting a general purpose monitor:

  o    How flexible are the configuration files? Can different parts of the
    monitor be disabled? Can the monitor be configured so that certain
    executables can perform suspect actions? For example, a self-modifying
    executable will still need to be able to modify itself.
  o    What types of suspect behavior are monitored? The more types of behavior
    monitored, the better. A flexible configuration to select from the set
    of features is desirable.
  o    Can the monitor be reconfigured to scan for additional virus techniques?
    Are updates provided as new virus techniques are discovered?


6.3 Selecting an Access Control Shell

Access control shells may be implemented in software or as hybrid packages with
both hardware and software components. If encryption modules are required, they
can be designed as software or hardware. The following questions should be
considered when selecting an access control shell:

  o    What type of access control mechanism does the shell provide and does
    it fit your security policy?
  o    If encryption is employed, what is the strength of the algorithms used?
    In general, publicly scrutinized algorithms are to be preferable to
    secret, proprietary algorithms where you are depending on the secrecy of
    the algorithm, rather than secrecy of the key.
  o    How strong are the identification and authentication mechanisms?
    provides basic criteria for analyzing the strength of these mechanisms.
  o    Are the passwords themselves adequately protected? Passwords should
    never be stored in cleartext.


6.4 Selecting a Change Detector

Due to cost considerations, change detection tools are usually implemented in
software. However, hardware implementations do speed the calculation of
cryptographic checksums. The following questions should be considered when
selecting a change detector:



  o    What kind of checksum algorithm does the tool use - CRC or
    cryptographic? CRC algorithms are faster. Cryptographic checksums are
    more secure.
  o    Can the tool be configured to skip executables that are known to be
    self-modifying? Consistent false positives will eventually cause the
    end-user to ignore the reports.
  o    How are the checksums stored? Some tools create a checksum file for
    every executable, which tends to clutter the file system and wastes
    disk space. Other tools store all checksums in a single file. Not only
    is this technique a more efficient use of disk space, but it also
    allows the user to store the checksum file off-line (e.g., on a floppy).

6.5 Selecting an Identification Tool

The following questions should be considered when selecting a scanner for
identification:

  o    How many viruses does it detect? How many different viruses are
    identified? The former asks how many different viruses are detected,
    whereas the latter asks how many different names are assigned to these
    different viruses. If a scanner is using signature strings, signatures
    can appear in variants. These questions will give some understanding
    regarding the level of precision provided by a particular tool.
  o    What names are used by the identification tool? Many viruses have
    numerous "aliases," so different scanners will produce different names
    for the same infection. This is especially true with IBM PC viruses.
    The identification feature of the scanner is only useful if the scanner
    comes with a virus catalog or uses the same nameset as an available
    catalog.


Precise identification tools will be more useful when they become available,
although the same limitations regarding a virus information catalog will still
apply.

6.6 Selecting a Removal Tool

Removal tools are more difficult to evaluate, but the following items may be of
assistance:

  o    Ask for a list of viruses that can be removed, and the general level of
    accuracy. (For example, "75 of disinfections will result in a working
    executable.") Ask for a list of viruses that cannot be removed. Use
    the ratio for the basis of a rough comparison.
  o    Get a scanner and removal tool that work from the same naming space. The
    removal tool works on the basis of the virus you name. You need to
    supply it with the name by which it knows the virus. Matched
    identification and removal tools are required to make it work.










7.0 For Additional Information

The National Institute of Standards and Technology's Computer Security Division
maintains an electronic bulletin board system (BBS)  focusing on information
systems security issues. It is intended to encourage sharing of information
that will help users and managers better protect their data and systems. The
BBS contains the following types of information specific to the virus field:



  o    alerts regarding new viruses, Trojan horses, and other threats;
  o    anti-virus product reviews (IBM PC and Macintosh);
  o    technical papers on viruses, worms, and other threats;
  o    anti-virus freeware and shareware;
  o    and archives of the VIRUS-L forum.



Occasionally, the alerts contain signature strings to update scanners. The
anti-virus product reviews examine and evaluate specific tools. The papers
provide an extensive body of basic knowledge regarding these threats. The
VIRUS-L forum has served as a world-wide discussion forum for the exchange of
information regarding viruses since April 1988. The past issues are available
for download.

Access Information

The NIST Computer Security Resource Center BBS can be access via dial-up or
through the Internet via telnet:



    Dial-up access: [phone] (2400 baud or less)
             [phone] (9600 baud)

    Internet: telnet cs-bbs.ncsl.nist.gov (129.6.54.30)


References

[BP92] Lawrence E. Bassham III and W. Timothy Polk. "Precise Identification
of Computer Viruses", in the Proceedings of the 15th National Computer
Security Conference, 1992.

[Sku92] Fridrik Skulason.  "The Mutation Engine - The Final Nail?", Virus
Bulletin, pages 11-12, April 1992.

[Rad91] Yisrael Radai. "Checksumming Techniques for Anti-viral Purposes",
In "Proceedings of the First International Virus Bulletin Conference", 1991.

[Bon91] Vesselin Bontchev.  "The Bulgarian and Soviet Virus Factories", In
"Proceedings of the First International Virus Bulletin Conference", 1991.

[Coh92] Dr. Frederick Cohen. "Current Best Practices Against Computer Viruses
With Examples From The DOS Operating System", In "Proceedings of the Fifth
International Computer Virus & Security Conference", 1992.

[Sol92] Dr. Alan Solomon. "Mechanisms of Stealth", In "Proceedings of the Fifth
International Computer Virus & Security Conference", 1992.

[FIPS112] Password Usage. Federal Information Processing Standard (FIPS PUB)
112, National Institute of Standards and Technology, May 1985.

[WC89] John Wack and Lisa Carnahan. "Computer Viruses and Related Threats:
A Management Guide", Special Publication 500-166. National Institute of
Standards and Technology. August, 1989.

Gustavus J. Simmons, editor.  "Contemporary Cryptology: The Science of
Information Integrity", IEEE Press, 1992.


Index

see hardcopy.


Tables



Error       Scanner           Binary    Generic        Access
Type            Checksum   Analysis    Monitor        Shell
=============================================================================

False        I       F        F       F        F
Positive


False        I       N        F       F        F
Negative

I= Infrequent
F= Frequent
N= Never

            Table 1

            Scanner           Binary    Generic        Access
Criteria        Checksum   Analysis    Monitor        Shell
=============================================================================

Ease of        VG       A        P       P        A
Use


Admin.        L       L        H       H        H
Overhead

VG = Very Good
A = Average
P = Poor
L = Low
H = High

            Table 2


Tool        Add'l Functionality
=============================================

Scanner        Identification

Checksum    Detect known Trojan horses

Binary        Detect Trojan Horses
Analysis

Generic        Detect Trojan horses
Monitor

Access        Enforcing organizational
Shell        security policy


            Table 3

Point of   Scanner           Binary    Generic        Access
Detection        Checksum   Analysis    Monitor        Shell
=============================================================================

Static        YES       No        Yes       No        No
Executable


Replication    No       No        No       Yes        Yes
Phase

After        Yes       Yes        Yes        No        Yes
Infection

            Table 4